home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 4 / ETO Development Tools 4.iso / Essentials / MacApp Documentation / MacApp.TECH$ Archives / 1990 / Oct 90 / MacApp.Tech$ 10⁄26⁄90 / 2248-Re Auto-Initialized -Oct90 < prev    next >
Encoding:
Text File  |  1991-03-06  |  2.5 KB  |  52 lines  |  [TEXT/GEOL]
  1. Item    8265122                         25-Oct-90        14:28PDT
  2.  
  3. From:   V0683                           Amoco Tech, Eric Berdahl,VAR
  4.  
  5. To:     MACAPP.TECH$                    MacApp Technical
  6.         LENOIL                          Lenoil, Robert
  7.  
  8. Sub:    Re: Auto-Initialized Objects
  9.  
  10. Robert,
  11.  
  12. Bravo!  I like what I see in your change to MakeNewInstance.  Once again, you
  13. demonstrate that MacApp has the built-in capacity to emulate higher order
  14. object concepts.  Some time ago, the concept of assertions and error handling
  15. was raised (no pun intended).  The resulting conversations showed clearly that
  16. MacApp already had an assertion mechanism, and that direct language support was
  17. not neccessary (although it's alway nice to have…).
  18.  
  19. Now, we see that a constructor mechanism is possible within MacApp via
  20. MakeNewInstance and TMyObject::Initialize.  Reading through your discussion,
  21. though, I'd like to emphasize one particular point.  Constructors (read: the
  22. Initialize method) is meant to put the object into a known (read: safe) state!
  23. Many problems beginning C++ programmers have with the constructor mechanism is
  24. that they try to do things that can fail, and when a failure occurs, they are
  25. left swinging in the breeze.  Learn from the mistakes of others and only do
  26. default initializations in your constructors (read: Initialize methods)!
  27.  
  28. Now, I have a devil's advocate question for you.  Is the only benefit of your
  29. change the loss of numerous FailNIL calls after allocation?  I grant you that
  30. constructors are nice, but I still have to call the IMyObject method anyway, so
  31. why shouldn't I just construct in IMyObject and follow with the initialization?
  32. Please don't misunderstand, I like what I see, but I'm interested in your
  33. thoughts for "the next step" in this process.
  34.  
  35. As a possible answer, I would propose that we gain good object design.  That
  36. is, constructors construct and initializers (read: IMyObject methods)
  37. initialize.  By splitting the two operations into two methods, we gain good
  38. object definition.
  39.  
  40. A second possible answer is that this Initialization will also allow TView
  41. subclasses to be initialized from the appropriate IRes methods, meaning I don't
  42. have to override IRes and IMyObject (well, you know), only Initialize.  Thus,
  43. we come to an interesting problem.  If I need to do non-trivial initialization
  44. (ie: maybe allocate some memory, etc), IRes must still be overridden as well as
  45. IMyObject.  Questions, questions, questions.
  46.  
  47. Stirring the soup,
  48. Eric Berdahl
  49. Amoco Technology Company
  50. AppleLink:  V0683
  51.  
  52.